Configuring SIP Interfaces

The SIP Interfaces table lets you configure up to 1,200 (SE), 40 (VE/CE 2 GB), 200 (VE/CE 3 GB), 400 (VE/CE 4 GB), 800 (VE/CE 8 GB), and 1,200 (VE/CE 16-64 GB) SIP Interfaces. A SIP Interface represents a Layer-3 network in your deployment environment, by defining a local, listening port number and type (e.g., UDP), and assigning an IP network interface for SIP signaling traffic. For example, if your deployment consists of an IP PBX in the LAN, a SIP Trunk in the WAN, and remote far-end users in the WAN, you would need to configure a SIP Interface for each of these SIP entities. You can also configure various optional features for the SIP Interface such as assigning it a Media Realm, blocking calls received on the SIP Interface from users not registered with the device, and enabling direct media (media bypass).

Each SIP Interface can be associated with only one SRD. As the SRD configuration entity represents your VoIP deployment SIP network (Layer 5), you need to associate your SIP Interfaces with a specific SRD in order to represent your Layer-3 networks. For most deployments (except multi-tenant deployments), your SRD represents your entire network and thus, only one SRD is required. The device provides a default SRD and in such scenarios where only a single SRD is required, your SIP Interfaces are automatically assigned to the default SRD. Therefore, there is no need to even handle SRD configuration entity.

Once configured, you can apply SIP Interfaces to calls, by assigning them to the following configuration entities in their respective tables:

■ (Mandatory) Proxy Set to specify the SIP Interface for communication with the proxy server (i.e., IP Group). For more information, see Configuring Proxy Sets.
■ Intrusion Detection System (IDS) for applying the IDS policy to a specific SIP Interface. For more information, see Configuring IDS Policies.
■ IP-to-IP Routing rules for specifying the destination SIP Interface to where you want to route the call. For more information, see Configuring SBC IP-to-IP Routing Rules.
■ Classification rules for specifying the SIP Interface as a matching characteristic of the incoming call. This is especially useful for the single SRD-configuration topology, where each SIP Interface represents a Layer-3 network (SIP entity). Therefore, classification of calls to IP Groups (SIP entities) can be based on SIP Interface.

The SIP Interface can also be used for tag-based classification of incoming SIP dialogs if the SIP Interface is configured with a Call Setup Rule Set ID that determines the source tag. For more information, see Configuring Classification Based on Tags.

For more information on classification, see Configuring Classification Rules.

■ Tel-to-IP Routing rules for specifying the destination SIP Interface to where you want to route Tel-to-IP calls. For more information, see Configuring Tel-to-IP Routing Rules.
■ IP-to-Trunk Group Routing rules for specifying the SIP Interface as a matching characteristics for the incoming IP call.

The device terminates active calls associated with a SIP Interface if you do one of the following:

● Delete the associated SIP Interface.
● Edit any of the following fields of the associated SIP Interface: 'Application Type', 'UDP Port, 'TCP Port', 'TLS Port' or 'SRD' fields.
● Edit or delete a network interface in the IP Interfaces table that is associated with the SIP Interface.

The following procedure describes how to configure SIP interfaces through the Web interface. You can also configure it through ini file [SIPInterface] or CLI (configure voip > sip-interface).

➢ To configure a SIP Interface:
1. Open the SIP Interfaces table (Setup menu > Signaling & Media tab > Core Entities folder > SIP Interfaces).
2. Click New; the following dialog box appears:

3. Configure a SIP Interface according to the parameters described in the table below.
4. Click Apply.

SIP Interfaces table Parameter Descriptions

Parameter

Description

'SRD'

srd-name

[SRDName]

Assigns an SRD to the SIP Interface.

If only one SRD is configured in the SRDs table, the SRD is assigned to the SIP Interface by default. If multiple SRDs are configured in the SRDs table, no value is defined and you must assign an SRD.

To configure SRDs, see Configuring SRDs.

Note:

■ The parameter is mandatory.
■ You can assign the same SRD to multiple SIP Interfaces .

General

'Index'

[Index]

Defines an index for the new table row.

Note: Each row must be configured with a unique index.

'Name'

interface-name

[InterfaceName]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters. By default, if you do not configure a name, the device automatically assigns the name "<row index>" (e.g., "SIPInterface_1" when added to Index 1).

Note:

■ The parameter value can't contain a forward slash (/).
■ The parameter value can't be configured with the character string "any" (upper or lower case).

'Topology Location'

topology-location

[TopologyLocation]

Defines the display location of the SIP Interface in the Topology view in the Web interface.

■ [0] Down = (Default) The SIP Interface element is displayed on the lower border of the view.
■ [1] Up = The SIP Interface element is displayed on the upper border of the view.

For more information on the Topology view, see Building and Viewing SIP Entities in Topology View.

'Network Interface'

network-interface

[NetworkInterface]

Assigns an IP Interface to the SIP Interface.

By default, no value is defined.

To configure IP Interfaces, see Configuring IP Network Interfaces.

Note:

■ The parameter is mandatory.
■ The 'Application Type' parameter of the assigned IP Interface must at least include "Control".
■ For SCTP multi-homing, the parameter defines the primary local IP address (IP Interface). If you want to configure a secondary local IP address (IP Interface), use the 'SCTP Secondary Network Interface' parameter (below). For more information on SCTP with multi-homing, see Configuring SCTP Multi-homing

'Application Type'

application-type

[ApplicationType]

Defines the application for which the SIP Interface is used.

■ [2] SBC = SBC application.

'UDP Port'

udp-port

[UDPPort]

Defines the device's listening and source port for SIP signaling traffic over UDP.

The valid range is 1 to 65534. The default is 5060.

Note:

■ The port number must be different from ports configured for RTP traffic (i.e., ports configured for Media Realms and Media Realm Extensions) using the same IP network interface. For example, if the RTP port range is 6000 to 6999, the SIP port can either be less than 6000 or greater than 6999.
■ Each SIP Interface must have a unique UDP signaling port within its underlying network interface (i.e., no port overlapping between such SIP Interfaces). For example:
✔ Valid configuration:
● SIP Interface #0: 'UDP Port' = 6010; 'Network Interface' = #0
● SIP Interface #1: 'UDP Port' = 6010; 'Network Interface' = #1
✔ Invalid configuration:
● SIP Interface #0: 'UDP Port' = 6010; 'Network Interface' = #0
● SIP Interface #1: 'UDP Port' = 6010; 'Network Interface' = #0

'TCP Port'

tcp-port

[TCPPort]

Defines the device's listening port for SIP signaling traffic over TCP.

The valid range is 1 to 65534. The default is 5060.

Note:

■ For the specific SIP Interface, the TCP port number must be different from the TLS port number (configured by the 'TLS Port' parameter below).
■ The port must be different from the TCP port configured for Media Realms and Media Realm Extensions that use the same IP Interface.
■ The source ports used for outgoing TCP connections are not configurable and are dynamically determined by the device in the range of 32,768-61,000.
■ Each SIP Interface must have a unique TCP signaling port within its underlying network interface (i.e., no port overlapping between such SIP Interfaces). For example:
✔ Valid configuration:
● SIP Interface #0: 'TCP Port' = 6010; 'Network Interface' = #0
● SIP Interface #1: 'TCP Port' = 6010; 'Network Interface' = #1
✔ Invalid configuration:
● SIP Interface #0: 'TCP Port' = 6010; 'Network Interface' = #0
● SIP Interface #1: 'TCP Port' = 6010; 'Network Interface' = #0

'TLS Port'

tls-port

[TLSPort]

Defines the device's listening port for SIP signaling traffic over TLS.

The valid range is 1 to 65534. The default is 5061.

Note:

■ For the specific SIP Interface, the TLS port number must be different from the TCP port number (configured by the 'TCP Port' parameter above).
■ The port must be different from the TCP port configured for Media Realms and Media Realm Extensions that use the same IP Interface.
■ The source ports used for outgoing TLS connections are not configurable and are dynamically determined by the device in the range of 32,768-61,000.
■ Each SIP Interface must have a unique TLS signaling port within its underlying network interface (i.e., no port overlapping between such SIP Interfaces). For example:
✔ Valid configuration:
● SIP Interface #0: 'TLS Port' = 6020; 'Network Interface' = #0
● SIP Interface #1: 'TLS Port' = 6020; 'Network Interface' = #1
✔ Invalid configuration:
● SIP Interface #0: 'TLS Port' = 6020; 'Network Interface' = #0
● SIP Interface #1: 'TLS Port' = 6020; 'Network Interface' = #0

'SCTP Port'

sctp-port

[SCTPPort]

Defines the local SCTP port on which the device listens for inbound SCTP connections (i.e., SIP signaling over SCTP).

The valid range is 0 to 65534. The default is 0 (i.e., SCTP is disabled).

Note: Each SIP Interface must have a unique SCTP port number (i.e., no two SIP Interfaces can have the same port number - no port overlapping).

'SCTP Secondary Network Interface'

sctp-second-network-interface

[SCTPSecondaryNetworkInterface]

Assigns an additional IP Interface to the SIP Interface, which serves as the secondary local IP address for SCTP multi-homing. For more information on SCTP with multi-homing, see Configuring SCTP Multi-homing

By default, no value is defined.

To configure IP Interfaces, see Configuring IP Network Interfaces.

Note:

■ The 'Application Type' parameter of the assigned IP Interface must at least include "Control".
■ To configure the primary local IP address (IP Interface) for SCTP multi-homing, use the 'Network Interface' parameter (above).
■ You must also configure the SCTP port, using the 'SCTP Port' parameter (above).

'Additional UDP Ports'

additional-udp-ports

[AdditionalUDPPorts]

Defines a port range for the device's local, listening and source ports for SIP signaling traffic over UDP. The parameter can be used for the following features:

■ Assigning a unique port per registered user (User-type IP Group) on the leg interfacing with the proxy server (Server-type IP Group). For enabling this feature and for more information, see the 'User UDP Port Assignment' parameter in the IP Groups table.
■ Assigning a specific local port to each SIP entity (e.g., PBX) communicating with a common SIP entity (e.g., proxy server). This is the port on the leg interfacing with the proxy server. In other words, the SIP Interface associated with the proxy server. For more information, see Configuring Specific UDP Ports using Tag-based Routing.
■ Assigning a unique port for each Account registering with the same Serving IP Group (registrar server). For more information, see Configuring Registration Accounts.

The valid range is 1,025 to 65535. The range is configured using the syntax x-y, where x is the starting port and y the ending port of the range (e.g., 6000-7000). By default, the parameter is not configured.

Note:

■ To configure whether the device keeps the configured ports (sockets) open or opens them only when needed, use the SIP Interface's 'Additional UDP Ports Mode' parameter (below).
■ The parameter's port range value must not overlap with the UDP port, which is configured by the 'UDP Port' parameter. For example, if the 'UDP Port' parameter is configured to 5070, you cannot configure the 'Additional UDP Ports' parameter with a range of 5060-6000.
■ The parameter's port range value must not overlap with UDP port ranges of Media Realms and Media Realm Extensions that are configured on the same network interface. For example, if the RTP port range is 6000-6999, you must configure the 'Additional UDP Ports' parameter to a range that is less than 6000 or greater than 6999.
■ The maximum number of ports in the range is limited to the maximum number of licensed registered SBC users as specified in the License Key installed on the device, or the maximum number of IP Groups that can be configured (see Configuring IP Groups) - the higher of the two determines it. For example, if the License Key allows 20 users and the maximum IP Groups that can be configured is 10, then the maximum number of ports is 20.

'Additional UDP Ports Mode'

additional-udp-ports-mode

[AdditionalUDPPortsMode]

Enables the device to open sockets (ports) for signaling only when needed. The parameter applies to the Additional UDP Port feature with dynamic port allocation (see the 'Additional UDP Ports' parameter, above). This allows you to configure the additional UDP port range without having to make sure that the total number of configured ports are within the maximum, as defined by the device's License Key.

■ [0] Always Open = (Default) The device keeps the ports (sockets) that are configured in the SIP Interface's 'Additional UDP Ports' parameter, open all the time.
■ [1] Open When Used = For the ports (sockets) that are configured in the SIP Interface's 'Additional UDP Ports' parameter, the device opens a port only when it is used. A port is needed when the device initiates registration with an external SIP entity for a SIP Account (sent to the Account's Serving IP Group), or forwards a registration request from a user (IP Group) to a proxy (Server-type IP Group). This option is applicable only to dynamic port allocation, where a port is allocated on the outgoing REGISTER message and closed when the registration expires. For HA systems, upon a switchover, all the ports used in the active device are also opened on the redundant device (now active), so that the SIP entity is reachable. Ports that are not configured by the SIP Interface's 'Additional UDP Ports' parameter are closed. The option is applicable only when the SIP Interface's 'Additional UDP Ports' parameter is configured and enabled for a Server-type IP Group (IP Group's 'User UDP Port Assignment' parameter) and/or SIP Account (Account's 'UDP Port Assignment' parameter).

Note:

■ For static port allocation (i.e., using additional UDP ports feature for assigning a specific local port to each SIP entity), configure the parameter to Always Open.

'Encapsulating Protocol'

encapsulating-protocol

[EncapsulatingProtocol]

Defines the type of incoming traffic (SIP messages) expected on the SIP Interface.

■ [0] No Encapsulation = (Default) Regular (non-WebSocket) traffic.
■ [1] WebSocket = Traffic received on the SIP Interface is identified by the device as WebSocket signaling traffic (encapsulated by WebSocket frames). For outgoing traffic, the device encapsulates the traffic using the WebSocket protocol (frames) on the TCP/TLS ports.

For more information on WebSocket, see SIP over WebSocket.

Note: WebSocket encapsulation is not supported for UDP ports.

'Enable TCP Keepalive'

tcp-keepalive-enable

[TCPKeepaliveEnable]

Enables the TCP Keep-Alive mechanism with the IP entity on this SIP Interface. TCP keep-alive can be used, for example, to keep a NAT entry open for clients located behind a NAT server, or simply to check that the connection to the IP entity is available.

■ [0] Disable (default)
■ [1] Enable

Note: To configure TCP keepalive, use the following parameters: [TCPKeepAliveTime], [TCPKeepAliveInterval], and [TCPKeepAliveRetry].

'Used By Routing Server'

used-by-routing-server

[UsedByRoutingServer]

Enables the SIP Interface to be used by a third-party routing server or ARM for call routing decisions.

■ [0] Not Used (default)
■ [1] Used

For more information on the third-party routing server or ARM feature, see Centralized Third-Party Routing Server.

'Pre-Parsing Manipulation Set'

pre-parsing-man-set

[PreParsingManSetName]

Assigns a Pre-Parsing Manipulation Set to the SIP Interface. This lets you apply pre-parsing SIP message manipulation rules on any incoming SIP message received on this SIP Interface.

By default, no Pre-Parsing Manipulation Set is assigned.

To configure Pre-Parsing Manipulation Sets, see Configuring Pre-parsing Manipulation Rules.

Note:

■ Pre-Parsing Manipulation is done only on incoming calls.
■ The device performs Pre-Parsing Manipulation before Pre-Classification Manipulation and Classification.

'CAC Profile'

cac-profile

[AdmissionProfile]

Assigns a Call Admission Control Profile (CAC rules) to the SIP Interface.

By default, no value is defined.

To configure CAC Profiles, see Configuring Call Admission Control.

Classification

'Classification Failure Response Type'

classification-fail-response-type

[ClassificationFailureResponseType]

Defines the SIP response code that the device sends if a received SIP request (OPTIONS, REGISTER, or INVITE) fails the SBC Classification process.

The valid value can be a SIP response code from 400 through 699, or it can be set to 0 to not send any response at all. The default response code is 500 (Server Internal Error).

This feature is important for preventing Denial of Service (DoS) attacks, typically initiated from the WAN. Malicious attackers can use SIP scanners to detect ports used by SIP devices. These scanners scan devices by sending UDP packets containing a SIP request to a range of specified IP addresses, listing those that return a valid SIP response. Once the scanner finds a device that supports SIP, it extracts information from the response and identifies the type of device (IP address and name) and can execute DoS attacks. A way to defend the device against such attacks is to not send a SIP reject response to these unclassified "calls" so that the attacker assumes that no device exists at such an IP address and port.

Note:

■ The parameter is applicable only if you configure the device to reject unclassified calls, which is done using the 'Unclassified Calls' parameter (see Configuring Classification Rules).

'Pre Classification Manipulation Set ID'

preclassification-manset

[PreClassificationManipulationSet]

Assigns a Message Manipulation Set ID to the SIP Interface. This lets you apply SIP message manipulation rules on incoming SIP initiating-dialog request messages (not in-dialog), received on this SIP Interface, prior to the Classification process.

By default, no Message Manipulation Set ID is defined.

To configure Message Manipulation rules, see Configuring SIP Message Manipulation.

Note:

■ The Message Manipulation Set assigned to a SIP Interface that is associated with an outgoing call, is ignored. Only the Message Manipulation Set assigned to the associated IP Group is applied to the outgoing call.
■ If both the SIP Interface and IP Group associated with the incoming call are assigned a Message Manipulation Set, the one assigned to the SIP Interface is applied first.
■ If Classification fails or the request is rejected prior to the Classification stage, then manipulation rules according to this parameter are applied to the reject response. In this case, the device adds a Reason header to the reject response. If routing fails, manipulation on the reject response is according to the 'Outbound Message Manipulation Set' parameter of the classified IP Group. When a Reason header is added to the reject response, its value is according to the type of failure:
✔ Routing failure: "General Routing Failure"
✔ Classification failure: "Classification Failure"
✔ Pre-Classification rejection due to device overload: "Board In Overload"
✔ Pre-Classification rejection due to locked device: "Board Is Locked"
✔ Pre-Classification rejection due to too many SIP headers in the request: "Header Overflow"
✔ Post-Classification failure of a REGISTER request when the source IP Group doesn't allow registers from the IP Group: "IPGroup Registration Mode Configuration"

'Call Setup Rules Set ID'

call-setup-rules-set-id

[CallSetupRulesSetId]

Assigns a Call Setup Rules Set ID to the SIP Interface. The Call Setup Rule is run before the Classification stage.

By default, no Call Setup Rules Set ID is defined.

To configure Call Setup Rules, see Configuring Call Setup Rules.

Call Setup Rules can be used for Classification of incoming calls to IP Groups based on tags (source), as described in Configuring Classification Based on Tags.

Note:

■ Call Setup Rules that are triggered from the SIP Interfaces table are done after identifying the incoming SIP Interface, but before classification, manipulation and routing. It can run synchronous operations including Dial Plan queries, but it can't run asynchronous queries (LDAP, ENUM, and HTTP).
■ Call Setup Rules can be used to generated source and destination tags. For classification, only source tags are used.
■ Using Call Setup Rules with the SIP Interface is suitable for actions that affect the source and the Classification of SIP dialog requests (such as modifying source tags or modifying the From header). It's not suitable for actions that affect the destination of the request and its routing (such as modifying the Request-URI header) because it might conflict with other features.

'Classify By Registration DB'

classify-by-reg-db

[ClassifyByRegDB]

Enables classification to IP Groups of incoming SIP dialog-initiating requests (e.g., INVITE) by the device’s users registration database.

■ [0] Disable = Disables classification of incoming dialog-initiating SIP requests by the users registration database. The device skips this classification stage and attempts to classify the SIP request by Proxy Set. If this classification stage fails, the device attempts classification by the Classification table (see Configuring Classification Rules).
■ [1] Enable = (Default) Enables classification of incoming dialog-initiating SIP requests by the users registration database.

Media

'Media Realm'

media-realm-name

[MediaRealm]

Assigns a Media Realm to the SIP Interface.

By default, no value is defined.

To configure Media Realms, see Configuring Media Realms.

'Direct Media'

sbc-direct-media

[SBCDirectMedia]

Enables direct media (RTP/SRTP) flow or media bypass (i.e., no Media Anchoring) between endpoints associated with the SIP Interface for SBC calls.

■ [0] Disable = (Default) Media Anchoring is employed, whereby the media stream traverses the device (and each leg uses a different coder or coder parameters).
■ [1] Enable = Direct Media is enabled (i.e., no Media Anchoring). Media stream flows directly between the endpoints (i.e., doesn't traverse the device).
■ [2] Enable when Same NAT = Direct Media is enabled (i.e., no Media Anchoring). Media stream flows directly between the endpoints if they are located behind the same NAT.

For more information on direct media, see Direct Media.

Note:

■ If the parameter is enabled for direct media and the two endpoints belong to the same SIP Interface, calls cannot be established if the following scenario exists:
✔ One of the endpoints is defined as a foreign user (for example, “follow me service”)
✔ and one endpoint is located on the WAN and the other on the LAN.

The reason for the above is that in direct media, the device doesn't interfere in the SIP signaling such as manipulation of IP addresses, which is necessary for calls between LAN and WAN.

■ To enable direct media for all calls, use the global parameter [SBCDirectMedia]. If the global parameter is enabled but the SIP Interface is disabled for direct media, direct media is employed for calls belonging to the SIP Interface. If the global parameter is disabled and the SIP Interface is enabled for direct media, direct media is employed for calls belonging to the SIP Interface.
■ If you enable direct media for the SIP Interface, make sure that your Media Realm provides sufficient ports, as media may traverse the device for mid-call services (e.g., call transfer).
■ If you have configured a SIP Recording rule (see SIPREC SIP-based Media Recording) for calls associated with this SIP Interface, the device automatically disables direct media for these calls (during their SIP signaling setup). This ensures that the media passes through the device so that it can be recorded and sent to the SRS. However, if you enable direct media using the [SBCDirectMedia] global parameter (i.e., for all calls), direct media is always enforced and calls will not be recorded.
■ Regardless of this parameter's settings, the device always handles calls whose incoming SIP dialog-initiating request (e.g., INVITE message) contains the proprietary SIP header 'X-AC-Action' with the value 'direct-media' (i.e., 'X-AC-Action: direct-media'), as direct media calls. These calls remain as direct media calls until they end.

'MSRP TCP Port'

msrp-tcp-port

[MSRPTCPPort]

Defines the listening TCP port for MSRP sessions.

The valid range is 4000 to 32768. The default is 0.

The port number is used in the SDP's 'a=path' line.

For more information on MSRP, see Configuring Message Session Relay Protocol.

Note: The port number must be unique for the SIP Interface (i.e., different to 'MSRP TLS Port', 'UDP Port', 'TCP Port' and 'TLS Port' parameters).

'MSRP TLS Port'

msrp-tls-port

[MSRPTLSPort]

Defines the listening TLS port for secured MSRP sessions (MSRPS).

The valid range is 4000 to 32768. The default is 0.

The port number is used in the SDP body's 'a=path' line.

For more information on MSRP, see Configuring Message Session Relay Protocol.

Note:

■ The port number must be unique for the SIP Interface (i.e., different to 'MSRP TCP Port', 'UDP Port', 'TCP Port' and 'TLS Port' parameters).
■ For MSRPS, you also need to assign a TLS Context to the SIP Interface (see 'TLS Context Name' parameter below).

Security

'TLS Context Name'

tls-context-name

[TLSContext]

Assigns a TLS Context (TLS configuration) to the SIP Interface.

The default TLS Context ("default" at Index 0) is assigned to the SIP Interface by default.

Note:

■ For incoming calls: The assigned TLS Context is used if no TLS Context is configured for the Proxy Set associated with the call or classification to an IP Group based on Proxy Set fails.
■ For outgoing calls: The assigned TLS Context is used if no TLS Context is configured for the Proxy Set associated with the call.
■ To configure TLS Contexts, see Configuring TLS Certificates.

'TLS Mutual Authentication'

tls-mutual-auth

[TLSMutualAuthentication]

Enables TLS mutual authentication for the SIP Interface (when the device acts as a server).

■ [0] Disable = Device doesn't request the client certificate for TLS connection on the SIP Interface.
■ [1] Enable = Device requires receipt and verification of the client certificate to establish the TLS connection on the SIP Interface.

By default, no value is defined and the [SIPSRequireClientCertificate] global parameter setting is applied.

'Message Policy'

message-policy-name

[MessagePolicyName]

Assigns a SIP message policy to the SIP interface.

To configure SIP Message Policy rules, see Configuring SIP Message Policy Rules.

'User Security Mode'

block-un-reg-users

[BlockUnRegUsers]

Defines the blocking (reject) policy for incoming SIP dialog-initiating requests (e.g., INVITE messages) from registered and unregistered users belonging to the SIP Interface.

■ [-1] Not Configured = (Default) The corresponding parameter in the SRDs table ('User Security Mode') of the SRD that is associated with the SIP Interface is applied.
■ [0] Accept All = Accepts requests from registered and unregistered users.
■ [1] Accept Registered Users = Accepts requests only from users registered with the device. Requests from users not registered are rejected.
■ [2] Accept Registered Users from Same Source = Accepts requests only from registered users whose source address is the same as that registered with the device (during the REGISTER message process). All other requests are rejected. If the transport protocol is UDP, the device verifies the IP address and port; otherwise, it verifies only the IP address. The verification is performed before any of the device's call handling processes (i.e., Classification, Manipulation and Routing).

Note:

■ The parameter is applicable only to calls belonging to User-type IP Groups.
■ The feature is not applicable to REGISTER requests.
■ The option, Accept Registered Users from Same Source [2] doesn't apply to registration refreshes. These requests are accepted even if the source address is different to that registered with the device.
■ When the device rejects a call, it sends a SIP 500 "Server Internal Error" response to the user. In addition, it reports the rejection (Dialog establish failure - Classification failure) using the Intrusion Detection System (IDS) feature (see Configuring IDS Policies), by sending an SNMP trap.
■ If you configure the parameter to any value other than default [-1], it overrides the corresponding parameter in the SRDs table ('User Security Mode') for the SRD associated with the SIP Interface.

'Enable Un-Authenticated Registrations'

enable-un-auth-registrs

[EnableUnAuthenticatedRegistrations]

Enables the device to accept REGISTER requests and register them in its registration database from new users that have not been authenticated by a proxy/registrar server (due to proxy down) and thus, re-routed to a User-type IP Group.

In normal operation scenarios in which the proxy server is available, the device forwards the REGISTER request to the proxy and if authenticated by the proxy (i.e., device receives a success response), the device adds the user to its registration database. The routing to the proxy is according to the SBC IP-to-IP Routing table where the destination is the proxy’s IP Group. However, when the proxy is unavailable (e.g., due to network connectivity loss), the device can accept REGISTER requests from new users if a matching alternative routing rule exists in the SBC IP-to-IP Routing table where the destination is the user’s User-type IP Group (i.e., call survivability scenarios) and if the parameter is enabled.

■ [-1] Not Configured = (Default) The corresponding parameter in the SRDs table ('Enable Un-Authenticated Registrations') of the SRD associated with the SIP Interface is applied.
■ [0] Disable = The device rejects REGISTER requests from new users that were not authenticated by a proxy server.
■ [1] Enable = The device accepts REGISTER requests from new users even if they were not authenticated by a proxy server, and registers the user in its registration database.

Note:

■ Regardless of the parameter, the device always accepts registration refreshes from users that are already registered in its database.
■ If configured to Disable or Enable, the parameter overrides the 'Enable Un-Authenticated Registrations' parameter settings of the SRD (in the SRDs table) that is associated with the SIP Interface.

'Max. Number of Registered Users'

max-reg-users

[MaxNumOfRegUsers]

Defines the maximum number of users belonging to the SIP Interface that can register with the device.

By default, no value is defined (i.e., the number of allowed user registrations is unlimited).